home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 13624 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.1 KB
  1. Path: mundook.cs.mu.OZ.AU!fjh
  2. From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 13:16:42 GMT
  6. Organization: Comp Sci, University of Melbourne
  7. Message-ID: <4kdnvq$3n8@mulga.cs.mu.OZ.AU>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <4kcer3$mi4@solutions.solon.com>
  9. NNTP-Posting-Host: mundook.cs.mu.oz.au
  10.  
  11. seebs@solutions.solon.com (Peter Seebach) writes:
  12.  
  13. >Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
  14. >>It is clear that (a) such code is broken and (b) the fact that
  15. >>it has undefined behaviour causes portability problems.
  16. >>What you said and what Robert Dewar said are not contradictory.
  17. >
  18. >Yes, they are.  There is no portability problem in the C language, or
  19. >the behavior of read().  It is not a portability program for a mistake
  20. >to behave randomly or differently on different machines.
  21.  
  22. No, it is definitely a portability problem if a mistake behaves
  23. differently on different machines.  It is a portability problem,
  24. because almost every non-trivial program contains mistakes, and so
  25. if a mistake can behave differently on different machines, that means
  26. that almost every non-trivial program will behave differently on
  27. different machines.  If behaving differently on different machines
  28. in ways not intended by the programmer isn't a portability problem,
  29. then I don't know what is!
  30.  
  31. >>... the undefined behaviour of read() and printf() both cause portability
  32. >>problems.
  33. >
  34. >No, they define the boundaries of a language; things beyond that boundary
  35. >are *supposed* to be undefined.  Since no program in the C language ever
  36. >runs into that behavior of a C implementation, it is not a portability
  37. >problem.
  38. ...
  39. >>Ha!  Obviously you have never tried porting any serious C programs.
  40. >
  41. >Any program which does that is not a C program; it has left the bounds of
  42. >defined behavior.
  43.  
  44. If you adopt that definition, then what I said -- that obviously
  45. you have never tried porting any serious C programs -- is still true,
  46. since no serious programs are written in 100% strictly conforming ANSI C.
  47.  
  48. However, such specious definitions belong in an ivory tower, not in the
  49. real world.  You're trying to define the problem away, but the problem
  50. is a very real problem which has very real costs.
  51.  
  52. >Further, that behavior is a flat out bug; it is never correct, and the
  53. >portability problem lies in the program, not the language spec.  The
  54. >program needs to be fixed.
  55.  
  56. No, the portability problem is the different behaviour of the program,
  57. when run on different systems.  It does not "lie in" the program -- it
  58. makes little sense to speak of behaviour "lying in" a program.  The
  59. behaviour is not something that has a single cause -- rather, it has a
  60. multitude of causes, some direct, and some indirect.  The problem is
  61. caused by the program AND by the implementation AND by the language spec.
  62.  
  63. Of course, you can't really assign blame to any of these abstract
  64. entities; blame, if it is to be assigned, must be assigned to the
  65. people responsible.  But you can't blame any of the people involved too
  66. much.  You can't really blame the language designers or language
  67. committee much; after all, they were just doing their best to specify
  68. the language in a way which allowed implementations some flexibility.
  69. You can't really blame the implementors, even though they may have
  70. known that defining things the way they did might lead to portability
  71. problems; after all, they were only following the spec!  And you can't
  72. really blame the programmers too much for making the occasional
  73. mistake; after all, they are only human!!
  74.  
  75. >No point blaming the language for incompetent or foolish programmers.
  76.  
  77. Every programmer has done something incompetent or foolish at some time.
  78.  
  79. Programming language design should take this, amoung other things,
  80. into account.
  81.  
  82. --
  83. Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
  84. WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
  85. PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
  86.